Software products were once considered to be best distributed via a single, monolithic package. This single package concept, when combined with transactional installation techniques, provided a robust installation mechanism that eliminated many issues that otherwise arose whenever a software installation failed at some random point during the installation process.
Today, however, software product vendors often want their products to be decomposed and recomposed as late as possible, whereby the single package solution is not as desirable. By way of example, in the effort to enter more international markets, software providers want to separate out their language resources into localized binaries that are independently distributed with respect to their corresponding worldwide software package.
As another example, technology providers have been increasing the size and scope of the redistributable runtimes upon which software developers depend. While there used to be relatively small redistributables like Visual C runtimes, Visual Basic runtimes and the like, the size of redistributions has grown to include technologies such as DirectX®, Microsoft® Foundation Classes (MFC) and Microsoft® Data Access (MDAC). It was thus common for an application to be much larger than the framework on which it was based; today, however, applications are often far smaller than the size of the redistributables packages, e.g., relative to the size of the .Net Framework (dotnetfx), Windows® Framework, and/or Windows® Presentation Foundation.
Still further, businesses want to reduce the cost and turnaround time of software package distribution to rapidly reach new target markets and to adjust their products for existing target markets. This has resulted in software makers dividing previously monolithic packages into smaller and smaller packages (sometimes referred to as a mini-package or micro-package).
Other reasons for dividing products also exist. For example, products may be divided based upon CPU architecture and servicing purposes.
In sum, monolithic software package distribution is no longer desirable or acceptable in many circumstances. However, decomposing a monolithic package into smaller packages results in losing the installation robustness that single package technology provided. For example, with multiple package installation, an installation failure tends to cause the subject machine to be in an indeterminate state, which corresponds to a very high recovery cost for administrators and/or package vendor support personnel.